Pyramid Of Doom (programming)

In computer programming, a common challenge facing systems programmers is that before an operation can be performed, a number of conditions must first be checked to confirm that the operation can be successfully performed. For example, before data can be written to a file, it must be confirmed that 1) the program has the file open for writing; 2) the program has the necessary permissions to write the data; 3) the data to be written is available; 4) the data to be written is of a valid size. A failure at any of these steps means that the write operation cannot be completed and an error should be returned to the calling program.

There are several ways that these multiple required tests can be written in the source code. One way is to check each condition in turn and if a condition fails, return from the subroutine at that point, indicating an error condition exists. This style of coding has the disadvantage that the subroutine returns from multiple (possibly many) points and some coding standards discourage having multiple return points.

Another way to is to check each condition and if the condition succeeds, enter a deeper block of code that checks the next condition and so on. The deepest enclosing block of code is only reached if all of the precondition tests are successful. This style of coding has the disadvantage that the indentation level increases with every test performed. If many tests are required, the enclosed blocks of code can march off the page to the right margin. This typographical effect is referred to as the pyramid of doom.

For example, the pyramid of doom is commonly seen when checking for null pointers or handling callbacks. Two examples of the term are related to a particular programming style in early versions of JavaScript, and the nesting of if statements that occurs in object-oriented programming languages when one of the objects may be a null pointer.

Examples

Most modern object-oriented programming languages use a coding style known as dot notation that allows multiple method calls to be written in a single line of code, each call separated by a period. For instance:

theWidth = windows("Main").views(5).size().width();

This code contains four different instructions; it first looks in the collection of windows for a window with the name "Main", then looks in that window's views collection for the 5th subview within it, then calls the size method to return a structure with the view's dimensions, and finally calls the width method on that structure to produce a result that is assigned to a variable name theWidth.

The problem with this approach is that the code assumes that all of these values exist. While it is reasonable to expect that a window will have a size and that size will have a width, it is not at all reasonable to assume that a window named "Main" will exist, nor that it has five subviews. If either of those assumptions is wrong, the corresponding call will result in a null pointer error.

To avoid this error, the programmer has to check every method call to ensure it returns a value. A safer version of the same code would be:

if windows.contains("Main")

If the programmer wishes to use that value based on whether or not it exists and is valid, the functional code inside the if statements is all pushed to the right, making it difficult to read longer lines. This often leads to attempts to "flatten" the code:

if windows.contains("Main")
if theWindow != null && theWindow.views.contains(5)
if theView != null

Or alternatively:

if !windows.contains("Main") else if !windows("Main").views.contains(5) else

This sort of programming construct is very common and a number of programming languages have added some sort of syntactic sugar to address this. For instance, Apple's Swift added the concept of optional chaining in if statements while Microsoft's C# 6.0 and Visual Basic 14 added the null-conditional operators ?. and ? JavaScript